Hello, Today we want to share some exciting news!

Fluid mixing saga Dominik Hello Factorians, Today I would like to talk to you about my favourite subject - fluid mixing and its prevention. It is a new mechanic introduced in 0.17 that seemed quite simple at first, but has been giving me nightmares ever since. A while ago I took on the task of updating the fluid system (FFF-260). The way it works in 0.16 is that the fluid boxes (the thing that holds the fluid and is contained in entities like pipes or refineries) had no organisation whatsoever except their connections. They would sit there and do nothing and then once per update send fluid somewhere. It had it's issues especially with symmetry, and when you happened to put some fluid where it did not belong, you could end up requiring major demolition works. My task was to develop a better algorithm to move the fluids, and a very very optional side task I had in mind was to do something about the fluids getting to wrong places and mixing. We started by organizing the fluid boxes into systems (connected FBs make a system) managed by a special fluid manager, and optimizing the heck out of it (FFF-271). Soon after, I started working on the new algorithm and anti fluid-mixing. Until then nobody really considered preventing the fluid mixing seriously as it did not seem possible. But when I thought about it, it did not seem that hard. The idea is to simply not allow any action that would lead to fluids getting where they are not supposed to go. When you build a steam pipeline, you should not need nor want it to touch another fluid. In principle, it would only require a few quite realistic mechanisms: A connected block of fluid boxes would either be fluid-free, or it would be locked to one fluid. Two such blocks can connect only if they are compatible - either one has no fluid lock, or they have the same fluid. An assembler can only set a recipe if it is compatible with the fluid locks on its fluid boxes. Have a migration from old saves that can contain mixing. By creating the fluid systems right before, number 1 was almost finished and we only needed to assign the lock. It would be set either by a fluid, or by a 'filter', which is a fluidbox that is set to use a fluid - such as a water pump using water, or assembler having some inputs/outputs given by a recipe. After a while I had both the fluid algorithm and the mixing done (FFF-274). The mixing was not that easy (like 5x more complicated) but it worked pretty well. As for the fluid algorithm, V453000 and Twinsen found some issues with waves on a macro scale, and because it was right before releasing the 0.17 experimental, we decided to hold it off on it for the time being (we have a new version now that seems okay, but has to wait for 0.17 becoming stable first). The mixing made it through though and seemed quite finished. It turned out that the work on it was at most one tenth complete. Some difficulties appeared already before the initial release, but that was only a hint of what would come later. One by one, then ten by ten, bugs started coming. The problem is that as often as not, they were not just little issues with simple fixes. Instead, over and over, they turned the current solution on its head and the code had to be completely rewritten in order to account for the new case. As of now, almost exactly half a year and many rewrites later, it is still not fully bug free. The number one issue was with Assembling machines. It turned out that their code was pretty messy and does not simply allow the checks I needed, so it had to be refactored. The next problem was that the check was not only required when setting a recipe on an existing assembler - as I naively thought - but in about one million different situations I would not dream existed. Building a fixed recipe assembler. Reviving an assembler. Rotating. Blueprint of an assembler. Blueprint with a recipe and a rotation placed over a ghost with a non-default rotation during a full moon. Teleport. Script building. Copy-paste settings. Any combination of these. Pretty much every case would go through different paths in the code and behave entirely differently. Fixing one would break another and so tons of tests had to be written. When these cases finally worked, it turned out that doing these operations when they fail (e.g. can’t rotate because it would cause mixing) brings another wave of issues. And then mods come and the complexity multiplies. All this, although in a more simple form, had to be done for all other entities that can use fluid too, such as inserters (mods...). Another number one issue are underground connections. When playing, you would not think twice about them but on a closer look they are all but simple. They have this (cough) uncomfortable feature (want to shoot myself) that you can build another underground pipe between them (or take it out) and a complex reconnection logic jumps in. It means that based on building order, connections are established and reestablished differently. This is a big thing when building a blueprint with many pipes, or loading a save game. But the largest issue is one tiny corner case with huge implications. Have two underground pipes that have different fluids, but are split by a third, and it gets removed. Until now mixing was theoretically completely avoidable, but here it was and there was nothing to stop it. As a result, a new concept is introduced - a blocked connection. An underground connection that would normally connect but can’t. Establishing it is the easier part. But when does it get fixed? An entity miles away gets rotated, that splits a fluid system, disconnecting the blocked connection from a fluid filter on the other side, and the connection should unblock. But even something as simple as a rotation contains fluid fixes and re-establishing of fluid boxes and if it fails, it still fixes the blocked connection in the process and it can’t be undone... You get the picture. And we are still talking about underground pipes, while anything can have underground connections, including said assemblers, which the previous code did not consider at all. The complexity just goes deeper and deeper, and Rseding is probably right that we should have never gone this way at all. So the bug fixing has been basically running in circles - clearing one batch of bugs, thinking that those were the last ones and the ordeal is finally over, only to find another batch (ideally from some bizzare modder idea) a few days later. Many times I wished that mods never existed. Nor multiplayer, or any players at all for that matter. About two months ago all seemed really fine, with basically no reports and just a few crashes in the automated crash reports. At that moment another nightmare materialized in the form of a talented volunteer bug tester named boskid, who took on a personal crusade to break the fluids to dust (I actually imagine him sitting in his dark room with evil laughter, dreaming about making my next day worse than the previous). In all seriousness, he has done a great deal of work with his bug testing, creating bizzare modded cases and testing scripts, and deserves a big thanks. He is actually coming to our offices next week, so follow the news for reports of developers falling out of windows. An example of a nice configuration he found (and I can’t fix). The whole time we were taking the offensive approach to mixing - crash the game when it happens - so that we know about bugs to fix them. Recently we have decided to put a stop to it and have the mixing automatically fix itself once it is detected, eyeing the end of this episode. Right now I have 3 mixing bugs on the list and I am sure those are the last, and mixing will be done (lying to myself is a way to cope with it) and the new fluid algorithm can come soon after :).

Hello there, I know a lot of you have been eagerly awaiting some solid information on the new planets, if so this blog is for you. Get comfy because it's a long one. As you already know, there are 4 new planets in the expansion. We will take an in-depth look at each planet's terrain, challenges, processes, technologies, and new gear, but not all at once. In some cases the planet content will be split into multiple parts. To kick things off I'll cover the terrain and natural aspects of the planet that is closest to being finished. I'll need to be in games master mode for this:

Hello, I'm alone here today, Tomas is on yoga camp. We will switch during the weekend, as he will get back, and I will start my paraglide course. I hope you wish me no injury so I can continue to develop Factorio without interruptions.

A few bugs left... WoW classic has been released, which means several of our top men have taken time off to spend hours raiding and having fun in Azeroth. This isn't great timing, as a few new bugs related to train signals appeared. We want to get these bugs solved before we do another release (another stable candidate). As it turns out, the only person with the skillset to fix these specific train signal bugs is also deep into levelling his Priest... (Kov on Pyrewood Village) We are still making the rest of the preparations for the stable release. We have started writing up the stable annoucement blog post, and have produced a 0.17 postcard image. Other than the few more critical rail bugs, there doesn't look like there is much else to block the stable release, on the forum we are down to 27 bugs. Since there are so few bugs left to deal with, some of the team has starting working on 'post-stable' features. Wheybags is working on the new campaign, Oxyd is diving into some detailed pathfinder improvements, and Rseding has started work on some particle optimizations. We will delve deeper into these topics and more in future FFFs, as we always love to do.

Hello, this week the Friday Facts are coming a little bit earlier. The reason is that in the evening I will be lost somewhere in the middle of Brno (second biggest city in the Czech Republic). I will participate in a popular annual deciphering game that is taking a place there. The 0.7.5 with another batch of bugfixes went out this Tuesday. Since then there has been no reports regarding major issues or crashes. Couple of teeny-tiny bugs were reported however that is not enough for us to make a new release now. So the 0.7.5 will become a stable version. Finally:) I have spent most of the time during the past week working on the trailer. The first version has been done already. There is a discussion thread on our forum (with a link to the unlisted video on youtube) where people can give us feedback about it. This is by far not finished. But we needed to get it out in order to start talking to the music & sound guy and give him some baseline to work with. Yesterday we had a long chat with Albert about the trailer and we agreed that the first scene (standing in the middle of the ruins) should be changed. Now it feels too out of the context from the rest. Apart from that we are quite happy with the general flow. Of course there are plenty of details that need to be tweaked so there is still a long way to go. On the other hand having all the trailer in the script makes things a hell lot easier for us. Changing things like the zoom behavior, camera movement or speed is just a breeze. Same goes for extending / shortening the scenes or adding a new scene all together. Another issue is the final video quality. There is a lot of movement going on in the trailer and currently after youtube compression, often the video is just blurry. We have used the 720p for now but that proved not to be enough. Oh and regarding the music. Just for fun we tried to run the Raymond Scott's Twilight in Turkey together with the trailer. It turned out to work surprisingly well, so one option is that the music would go in this kind of direction. Apart from preparing the 0.7.5 Michal spent most of the time on the new scenarios for the main campaign. It starts to slowly shape. At the moment there are 5 levels that introduce basic things like assembling machines, research, trains, etc. to the player in the course of playing. Often the player is not starting from the scratch but he can use already existing pieces of the factory. Writing the scenarios (and the trailer) is also a good opportunity for us to review, document and extend the Lua API. Kuba and Albert keep working together on the terrain. There are couple of variations of the dirt by now and Albert is now spending his evenings with the grassy terrain. Kuba made couple of Blender scripts to ease the manual terrain work. This way Albert can take advantage of generated tileable noise or terrain transitions. Also yesterday Kuba showed me a great picture he generated that I can't resist to share with you. In case that you always thought that there is a lot of recipes in the game and that the whole thing is too complex, then worry no more. Here is an ultimate Factorio recipe cheatsheet for you: As usual there is a post on our forum where you can discuss this update.

Hello, it is a great weather here. The weather is actually so nice, that I had to take 4 day vacation last week. It was a paragliding vacation placed in Italy, Basano. It was my first proper flying with the "Factorio" paraglide and the experience was extra fantastic. I was able to turn off the programming/Factorio part of the brain for the time, which is very hard to achieve usually. This allowed me to recharge and clear the head so I can work on Factorio with the full enthusiasm again.

I've done several optimizations around the game update over the past few game versions but in 0.15 I decided to also look at some of the game GUIs. In particular there are 3 GUIs which tend to take a large amount of time when visible: the production stats, the trains view, and blueprint tooltip previews.

Hello Factoriators, greeting from rainy Prague. Bad weather makes perfect environment for making good development progress and that is imho exactly we did this week. Just before we start I have to share this picture I came across when checking out Factorio subreddit. I find it super funny. The Factorio subreddit has an active community and it is becoming a good alternative to the forums.

Good evening everyone, we have spent the week doing various stuff. Playing and testing the multiplayer game, working on some promised features (yes, talking about the tank) and also sorting out administrative issues. In the end we have signed an agreement to rent a place in the Prague city center so since this week we officially have an office space. The place is still empty but we are already looking for furniture and computer equipment to turn an ordinary looking flat it into a true Factorio HQ.